The advent of networked data processing systems, and particularly the network of networks referred to as the Internet, has spurred the introduction of distributed data processing services. In such systems, a client, typically remotely connected to the service provider via one or more networks, accesses data processing services which are implemented on the remote data processing system which then returns the results of the data processing activity to the client.
It has become common to use the services represented by the World Wide Web (WWW) with it's graphical user interface (GUI) orientation to provide the interface to such distributed data processing services. Typically, in such data processing systems, the client sends a request to a server. On the server side, the system builds a Web page for returning the response to the requesting client. The Web page includes code that may be interpreted on a Web browser running on the client machine which, in response to the code, displays the page on a conventional display such as a CRT or LCD monitor connected to the client machine. The Web page may include dynamic data, that is, data that is changing in time, indeed, may be continuously changing in time; stock quotations are an example. This dynamic data may be generated by server-side application software. This application software need not reside on the same hardware as the page server, but may be deployed on other systems that may be remote from both the client and the page server. Such distributed, application-to-application data processing implementations, which are typically XML-based request responses may, generically, be referred to as web services.
The dynamic data is generated in response to a Web services request issued by the client application based on information included in the code for the web page being executed. Typically, Web services requests are XML-based (XML refers to the eXtensible Markup language) requests encoded in SOAP (Simple Object Access Protocol) and use HTTP (HyperText Transport Protocol) as the transport mechanism. However, Web services requests are not required to use either XML, SOAP or HTTP.
To reduce traffic on the network, caching of Web service requests responses may be used. In this way, subsequent requests for the same web service may be served up from the cache. To associate cached information with an incoming request, an identifier is generated from the information in the incoming request to uniquely identify it.
The servicing of such a request may be understood by referring to FIG. 1 illustrating an exemplary process 100 for responding to a Web service request. In step 102, the incoming request is received. From the information in the request, an identifier is calculated in accordance with a predetermined algorithm.
If the identifier is in the cache, the associated response stored in the cache is served up, step 108. Otherwise, the request is issued to the Web services server. The response may then be cached along with the identifier from the original request, step 112.
The selection of information used to formulate an identifier affects the performance of a system in responding to end-user requests. The system may expend a significant fraction of its resources calculating identifiers and, if the selection criteria are poor, the hit rate will be low. Consequently, system resources are expended in fruitless calculations of identifiers and, particularly during peak periods, the response time to end-users may be adversely impacted.
Consequently, there is a need in the art for mechanisms to automatically adjust to caching utilization and, to autonomically adjust cache identifier specifications.